perm filename PASNOT.EJG[UP,DOC] blob sn#386372 filedate 1978-10-05 generic text, type C, neo UTF8
COMMENT ⊗   VALID 00003 PAGES
C REC  PAGE   DESCRIPTION
C00001 00001
C00002 00002
C00010 00003	* * * * *  from here on are local user notes from SU-AI community  * * * *
C00015 ENDMK
C⊗;

***********************************************************************
*	Note:	this  file is set for  append access.  Please append  *
*	your comments when you try the Pascal compiler.  Just say:    *
*	  @APP TTY:  DOC:PASCAL.NOTES				      *
*	and then type your comments, ending with a ↑Z.		      *
***********************************************************************

SUBJECT: Pascal compiler observations.


Observations on the Pascal compiler.
	(as made by J.JHENN)
1.  In @EXECUTE mode the /list option causes the listing to appear
    on the line printer.  This does not happen in @PASCAL mode.
2.  In @PASCAL mode:
	If /LIST is specified, LIST FILE must be.
	/CREF after the source file causes CROSS REFERENCE, with the 
	   following properties:
		A * is printed to which you give the name of the source
		file without extension.

		The list file (.LST) contains pretty printed listing 
		and cross reference.  The file with the source
		name and extension .NEW is a formatted listing.
3.  The compiler utilizes PPN, which is no problem, if you use
    your own directory.
4.  On the run time environment.
    Using READ/WRITE.  To get TTY (i.e. the teletype), use
    TTY as the file name. The default file names are INPUT for READ/READLN,
    and  OUTPUT for WRITE/WRITELN. MESSAGE is always sent to TTY.
5.  When the compiler starts using TTY.  It first prints a *,
    prompting to fill the input buffer.  Note that this occurs
    prior to executing other statements (including writes
    which are before your reads).  No big deal --
    just enter CR and then continue as usual.
END OF OBSERVATIONS.
-----------------------------------------------------------------------
A.ARMANDO, 01/12/78
Important details that are easy to forget and will give you problems:
  1.-  If you forget to put a star (*) after the names of any parameter
	file which is going to be used for input, it will be rewritten,
	instead of reset. This causes a new,empty version of the file 
	to be created, and your input is not accessible anymore. The 
	program will stop with the message INPUT DATA ERROR IN FILE ...
	when the first input is attempted.  
  2.-  If you give a device name, such as TTY: to the prompt for the 
	actual names of the parameter files, no error message will be 
	sent, but your description will be ignored, and the file name 
	will be assigned in the same way as if you hit return only.  
  3.-  Remember the way a real number is defined. If your program needs
	a real number as input, and at run time it takes a number such 
	as .3 or 456 or 23., it will report an INPUT DATA ERROR IN FILE ...
	 They should be typed as 0.3 and 456.0 and 23.0 .  
  4.-  When you are prompted for the file names for files INPUT and 
	OUTPUT, the only extensions allowed are INP and OUT respectively,
	and the name of the file should not exceed six characters. So, 
	AA.INP is a valid file name for INPUT, but ANY.THING and 
	LONGNAME.INP are not. For other parameter files, the only res-
	triction is size: up to 6 chars for the name, and up to 3 for
	the extension.
  5.-  If you use READLN on TTY, then at runtime you will have to type
	two <RETURN> instead of one. The first is taken as the end-of-line
	character, and the second indicates end of input, as usual.
-----------------------------------------------------------------------
On the USE of INPUT and OUTPUT as standard files.
          (observations by J.JHENN)

The standard files INPUT and OUTPUT are predeclared as TEXTFILES,
by the compiler.  They operate in two different ways.

First, if the files INPUT and OUTPUT appear in the file header,
then there names are prompted for.  They act as described 
in the previous note (by A.ARMANDO).

If the file names INPUT and OUTPUT do not appear in the file
header.  Then the files will have the names INPUT.. and OUTPUT..
respectively.  Additionally, both files will be reset and the
file OUTPUT.. will be rewritten (i.e. a new creation if it 
already exists - otherwise a new file).  This is equivalent
to putting INPUT*,OUTPUT in the file header and replying to the prompt
   		INPUT= input..
		OUTPUT= output..
__________________________________________________________________
A.ARMANDO  01/17/78
	Another warning:  INPUT and OUTPUT are predeclared for you by
	PASCAL, so they SHOULD NOT EVER be included by you in a VAR
	declaration. If you declare them, for some unknown reason they
	end up being declared to the system as BINARY, and you will not
	be able to read characters from INPUT.
----------------------------------------------------------------------
* * * * *  from here on are local user notes from SU-AI community  * * * *

∂05-Oct-78  0307	EJG  Kluge to allow large one-segment PASCAL programs

PDP10 PASCAL is quite strongly oriented towards using two-segment core
images, with the lower containing mostly variable information and the
upper containing pure code.  However, for address space reasons (at least)
it occasionally becomes desirable to run a PASCAL program in one segment,
to let it use all of one address space (2↑18 words).

This note describes a kluge which allows for this in a somewhat limited
and very unclean way.  Perhaps it will be obsoleted someday when someone
figures out how to "do it right," e.g. implements a switch similar to
SAIL's "/NOSAISEG".

First, the PASCAL DEBUG package makes a number of assumptions about
absolute locations of some data, so single-segment programs cannot be run
with DEBUG (*$D+*) turned on (until such dependencies are removed).
However, note that this does not exclude running with runtime tests
(*$T+*) turned on (as is the default).  The procedure outlined below will
load the PASCAL program with DDT, which can be used as an assembly-level
debugger if this is any help.

To start building the single-segment core image, make sure that no (*$D+*)
options appear in the source program which would invoke PASCAL DEBUG.
Also, chances are that you want to specify some large amount of runcore
for the program (or else you wouldn't be bothering with this procedure),
such as (*$R240*).  Then create the relocatable object file with a command
such as:
	.COMPILE FOOBAR
...which compiles FOOBAR.PAS into FOOBAR.REL.

Next use LINK to create the forced single-segment core image (containing
DDT), as follows:
	.R LINK
	*/SEGMENT:LOW=FOOBAR
	*/SEGMENT:LOW/SYSLIB=
	*/TEST:DDT=
	*/G=
(sometimes LINK exits with "Ill mem ref at user 10", but the core image it
builds seems to be complete enough to work anyway...sigh)

Now, before saving (or running) the core image, it is necessary to do a
small amount of patching with DDT, as follows (here things the user types
will be enclosed in braces "{}"):
	.{DDT<return>}
	FOOBAR$:  {jobsa[}  <some numbers>{<tab>}
	<some instruction>{<return>}
	{.+36/}  <some instruction>
...it may now be necessary to search about a bit with {<line feed>} and/or
{↑} (up arrow) to find the right three instructions, but once you find
them you proceed like this:
	40641/  HRRZM 16,.JBDA+3	{JFCL<line feed>}
	40642/  SKIPE .JBDA+6		{JFCL<line feed>}
	40643/  XCT .JBDA+6		{JFCL<line feed>}
	40644/  JRST 40357		{<CALL> or <CTRL-C>}

The single segment core image should now be set up, ready to be saved
with the SAVE command (not SSAVE), or run with the START command.  Believe
it or not this mess really does tend to work!  Good luck...